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ABSTRACT 


EtherNet/IP is an industrial protocol that is built on top of the TCP/IP protocol suite. Though 
extending TCP/IP connectivity to industrial control systems (ICS) has enabled operators to 
implement more agile practices, it also has made ICSs more readily accessible to the outside 
world. Embedded control systems on Navy afloat and ashore platforms utilize EtherNet/IP, 
making those platforms prime targets for cyber attack, buzzing technology can analyze the 
message structure of ICS protocols like EtherNet/IP to help inform users on the robustness 
of the implementation. This thesis explores a proprietary EtherNet/IP implementation to 
determine its susceptibility to malformed packets. ENIP buzz, a Scapy-based fuzzer, was 
built to test for potential security vulnerabilities in EtherNet/IP implementations. This 
custom fuzz testing tool verifies the robustness of target applications or devices in handling 
abnormal input data. Results of this effort revealed a previously unreported vulnerability 
in an industrial controller commonly used in Navy control systems that causes a Denial of 
Service (DoS) by a single malformed packet. 
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CHAPTER 1: 

Introduction 


Industrial Control Systems (ICS) are vital components to the operation and functioning 
of critical infrastructure systems. There are sixteen critical infrastructure sectors defined 
by the Department of Homeland Security (DHS) and most, if not all, utilizes some form 
of ICS to manage and operate their assets [I]. To serve the need for greater efficiency 
and automation, industrial control systems have been extended to operate over Ethernet. 
EtherNet/IP is an industry standard ICS protocol that is built on top of Ethernet and is used 
in Navy platforms ashore and afloat to serve the need for greater efficiency and automation. 
Ethernet-based technologies have enabled operators to implement more agile practices, but 
it also has significantly increased the exposure of these critical infrastructures to the outside 
world. 

The current lack of visibility into the lower layers of Navy control systems is a risk to 
the operational readiness and security of the warfighter. This thesis aims to improve 
security posture of afloat and ashore platforms by investigating potential vulnerabilities in 
the EtherNet/IP implementation of commercial ICS equipment commonly used in these 
platforms. 

1.1 Motivation 

Afloat and ashore control systems are protected by varying levels of boundary defense, 
but often have exploitable network interiors. In order to map vulnerabilities related to the 
network infrastructure, vulnerabilities within the underlying protocol must be considered. 

buzzing or fuzz testing is an analysis technique to verify the robustness of target applications 
or devices in handling abnormal input data, buzzing the implementations of control network 
protocols is an important step towards developing more secure industrial control systems. 
Voyiatzis et al. argue that control networks are well-suited for fuzz testing because the 
systems are likely to have been developed years ago, the source code and specification 
may not be available, a variety of vendor-specific implementations may exist, and Internet 
connectivity is increasingly integrated with such systems [2]. 
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1.1.1 Navy Relevance 

Devices communicating via EtherNet/IP are used in Navy control systems, including sim¬ 
ple I/O devices such as sensors and actuators, as well as complex control devices such as 
programmable logic controllers and industrial networking appliances. The machinery con¬ 
trol systems aboard Navy Ships use a number of fieldbus protocols, including EtherNet/IP, 
to satisfy a wide range of embedded shipboard systems that vary in size and complexity, 
e.g., combat weapon systems, Hull Mechanical and Electrical (HM&E) systems, and ship 
control systems [3]. The Navy has a keen interest in making these types of systems robust to 
cyber attacks. In particular, WeaselBoard—developed under the Speed-to-Eleet US Navy 
project—targets protecting Allen Bradley/Rockwell Automation (AB/RA) ICS components 
that communicate via EtherNet/IP [4]. Thus, black-box testing of the protocol stack for 
these devices is a natural extension of those priorities. 

1.2 Objectives 

Vulnerabilities in ICS protocol implementations have been found by fuzzing, but little 
information has been made publicly available on EtherNet/IP. The goal of this research 
is to develop a custom fuzz testing tool to stress test the EtherNet/IP implementation of 
select AB/RA devices. Our testing approach leverages remote fault detection techniques 
to identify faults triggered by fuzz testing. Our fuzzer is modeled after Scapy, a Python 
module used for packet parsing and crafting [5]. Its flexibility to send, sniff, dissect and 
forge network packets has made it a popular tool among penetration testers seeking to 
discover protocol vulnerabilities. 

1.3 Thesis Organization 

The thesis is organized as follows: Chapter 2 provides an overview of the EtherNet/IP 
protocol. Chapter 3 introduces fuzz testing and provides a technical survey of available ICS 
tools. Chapter 4 describes the design and approach that is applied to fuzzing EtherNet/IP. 
Chapter 5 discusses the implementation of our EtherNet/IP fuzzer and analyzes the results 
of our testing. Chapter 6 discusses suggestions for future work and summarizes the research 
effort. 


2 



CHAPTER 2: 

Background: EtherNet/IP and CIP Specification 


EtherNet/IP, or EtherNet Industrial Protocol, is an ICS protocol that encapsualtes the Com¬ 
mon Industrial Protocol (CIP) in its upper layers [6]. The EtherNet/IP and CIP protocol 
suite is managed by the Open DeviceNet Vendor Association (ODVA). ODVA publishes 
the The EtherNet/IP Specification and The CIP Specification and administers conformance 
testing to ensure compliance with the standard [6]. 

2.1 Common Industrial Protocol 

The Common Industrial Protocol, or CIP, provides messaging services for manufacturing 
automation and the functionality needed for configuration, safety, motion, control, syn¬ 
chronization and information applications [6]. CIP gives users the ability to incorporate 
these manufacturing applications with Ethernet networks [6]. Eigure 2.1 illustrates the four 
protocols—EtherNet/IP, CompoNet, ControlNet and DeviceNet—that use CIP’s application 
layer, application object libraries, and device profiles for the upper layers of their network 
protocol stack. It is only the lowest four layers of the OSI model that are network protocol 
dependent. 

2.1.1 CIP Objects 

CIP is an object-oriented protocol. The CIP family shares commonly defined objects and 
only a few are specific to the selected link layer [7]. According the specification, the CIP 
node is modeled as a set of Objects [8]. An Object is an abstract representation of a 
particular component within a product. A Class is a set of Objects of the same kind of 
system component. An Object Instance is the actual representation of a particular Object. 
An Instance of a Class share the same attributes, but has its own unique attribute values [8]. 
Eigure 2.2 illustrates multiple Object Instances within a Class of Objects that can reside in 
a CIP node [8]. 

The CIP object library supports general purpose network communications, network ser¬ 
vices, and automation functions used by industrial components such as analog and digital 
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Figure 2.1. CIP Common Layers 


This figure illustrates how EtherNet/IP, DeviceNet and ControlNet share the CIP 
Common layers. Source [6, Figure 2.1]: I. Open DeviceNet Vendor Association, 
“Ethernet/IP quick start for vendors handbook,” ODVA, Inc., Ann Arbor, Ml, Tech. 
Rep. PUB00035R0, 2008. 


input/output devices, Human Machine Interface (HMI), and motion control. To support 
interoperability, conformance with CIP standard ensures the same objects implemented by 
different devices behave identically. A group of objects used in a device is referred to as that 
device’s Object Model [8]. The Object Model in CIP is based on the producer-consumer 
communication model. 


2.2 EtherNet/IP 

EtherNet/IP is the name given to CIP over standard Ethernet. The EtherNet/IP standard 
defines port 44818 as the designated port over which EtherNet/IP devices accept TCP and 
UDP connections. Eigure 2.3 illustrates the relationship between EtherNet/IP and the OSI 
model. 
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An example of a CIP node, Object, and Object Instances. Source [8, Figure 2.2]: 
The CIP Networks Library Volume 1: Common Industrial Protocol, 3rd ed.. Open 
DeviceNet Vendor Association, Inc., Ann Arbor, Ml, November 2007. 
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Figure 2.3. EtherNet/IP and the OSI Model 

Relationship between EtherNet/IP and the OSI model. Source [6, Figure 2.3]: 
I. Open DeviceNet Vendor Association, “Ethernet/IP quick start for vendors hand¬ 
book,” ODVA, Inc., Ann Arbor, Ml, Tech. Rep. PUB00035R0, 2008. 


2.2.1 Types of EtherNet/IP Communications 

EtherNet/IP uses two primary types of eommunications: implieit and explieit [6]. For 
greater network efficieney, implicit messaging utilizes the CIP producer/consumer model 
[6]. This model enables a sending device (i.e., the producer) to exchange scheduled, 
time-critical control data to one or more receiving devices (i.e., the consumers) [6]. 

With implicit messaging, a CIP connection must be established [6]. Communication ses¬ 
sions related to a specific connection are assigned a unique connection identifier upon 
establishing a connection [6]. The CIP connection identifier acts as a dedicated commu- 
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nication path allowing multiple end-points to share data without the need to send the data 
multiple times [6]. Implicit messaging uses UDP and can be unicast or multicast [6]. 

Explicit messaging provides general request/reply (or client/server) communication between 
two devices and is used for non-real-time data. For EtherNet/IP, explicit messaging uses 
TCP and does not require establishing a CIP connection [6]. 


2.2.2 Types of EtherNet/IP Implementations 

EtherNet/IP may be implemented as software or hardware. ODVA has defined four hardware 
classifications: Explicit Message Server, Explicit Message Client, EO Adapter, and I/O 
Scanner [6]. An Explicit Message Server responds to explicit messages initiated by a Explicit 
Message Client. Alternatively, an Explicit Message Client initiates explicit messaging with 
other devices. An I/O adapter is also an explicit message server and receives implicit 
message requests, responding with its I/O data at the requested rate. An EO scanner 
initiates implicit messages with other EO adapter devices, and may support initiating 
explicit messages. At a minimum, all EtherNet/IP devices are required to support explicit 
server capabilities [6]. Figure 2.4 is a diagram of the four EtherNet/IP device classifications, 
including device examples. 
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Figure 2.4. EtherNet/IP Device Classification 

Matrix of Device Classifications and EtherNet/IP communications. Source [6, 
Figure 2.4]: I. Open DeviceNet Vendor Association, “Ethernet/IP quick start for 
vendors handbook,” ODVA, Inc., Ann Arbor, Ml, Tech. Rep. PUB00035R0, 2008. 
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This research focuses on the EtherNet/IP stack of a specific device, the Allen Bradley 
MicroLogix 1100. More details on this device will be discussed in the chapter on Design. 
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CHAPTER 3: 

ndustrial Control System Fuzzers 


Fuzzing or fuzz testing is a vulnerability analysis technique used to assess the robustness of 
target applications or devices in handling invalid, malformed, or unexpected input data. In 
general, fuzzers operate under two basic assumptions: faults contained in a target application 
can be triggered through input controlled by the user and the execution of a faulty portion 
of an application will result in some behavioral manifestation (e.g., bricking the device or 
producing unexpected output) [9]. Most systems are designed to work with specific inputs 
but should be robust enough to gracefully handle malformed data. Therefore, flaws found 
from fuzzing will correspond to a bug in the target (e.g., file, network protocol, embedded 
device, and software). 


Sutton divides general fuzz testing into five phases [10]. Figure 3.1 is a graphical represen¬ 
tation of the fuzzing phases: 



Figure 3.1. Fuzzing Phases 


1. Identify target. The target identification phase involves the selection of a target for 
vulnerability analysis. Target identification will likely guide what tool or technique 
will be applied. 
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2. Identify potential fuzz variables. Anything sent from the client to the target should be 
considered a potential fuzz variable. 

3. Generate fuzzed data. Depending upon the data format and the target, the identified 
input can be mutated or generated. Once input vectors have been identified, fuzz data 
must be mutated or generated randomly. 

4. Execute fuzzed data. The fuzzed data execution phase could involve opening a file, 
launching a target process, or sending a data packet to the target. 

5. Fault monitoring. The fault monitoring phase is responsible for monitoring the 
behavior of the system under test (SUT) in response to fuzzed data. 

Though fuzzers may differ in their support of these operations, fault monitoring is of 
particular importance. At its most basic level, a fuzzer might detect that a fault was triggered 
if the target crashes or becomes bricked, i.e., application is rendered unusable or is unable to 
accept a new connection [10]. More sophisticated fault detection may be achieved with the 
help of a debugger. For example, the Peach and Sulley fuzzing frameworks communicate 
directly with a debugger attached to the target application [10], [11]. Sutton et al. propose 
an alternative, where a debugger runs on the target platform to monitor exceptions and 
correlate fuzzing behavior with observed faults [10]. 

3.1 Fuzzing Methodologies 

While there is no universally-accepted taxonomy of fuzzing approaches, most of the lit¬ 
erature places fuzzers into one of two categories: mutation-based and generation-based. 
Mutation-based fuzzers apply transformations (mutations) on existing data samples to create 
test cases [12]. Generation-based fuzzers create test cases from models of SUT behavior. 
Each method has its own strengths and weaknesses. 

3.1.1 Mutation-Based Fuzzers 

Mutation-based fuzzers modify valid inputs by altering bytes to create fuzzed inputs [12]. 
Some mutation fuzzers utilize a description of the input fields, while other mutation fuzzers 
do not require any knowledge of the format; instead, they use heuristics to guess field 
structure and mutate each field [12]. Most mutation fuzzers extract data from recorded 
sessions for mutation, although some fuzzers intercept and mutate live traffic [12]. Mutation- 
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based fuzzing is considered a form of brute force testing in that the fuzzer starts with valid 
inputs and incrementally transforms every bit within the input [10]. This requires little 
up-front research and implementing a naive mutation-based is relatively straightforward. 
The SUT may employ complex logic infrequently invoked. Many fuzzing iterations may 
be required to achieve sufficient code coverage, though this challenge can be offset with 
automation. 

3.1.2 Generation-Based Fuzzers 

Generation-based fuzzers construct test cases employing rules defining a grammar-based 
specification for inputs. The most simplest fuzzers of this type create input data of random 
strings of bytes [12]. Some generation-based fuzzers must be configured using some input 
description or data model to generate test cases [10]. The generation-based approach 
requires up-front research to understand the specification or source code of the target. 
However, rather than using hard-coded test cases, a generation-based fuzzer uses grammar- 
based rules to dynamically pinpoint the portions of the file or packet that represent fuzzable 
variables. 


3.2 ICS Protocol Fuzzers 

In Table 3.1, we survey relevant fuzzers and fuzzing frameworks, highlighting, when appli¬ 
cable, those ICS protocols each supports. Smith and Francia [13] report on an EtherNet/IP 
and CIP fuzzer, but the code is not available. As far as we know, there is no open-source 
fuzzer supporting EtherNet/IP or CIP. 

In Table 3.1, we classify the surveyed software as either a custom fuzzer or a fuzzing 
framework. Custom, or one-off, fuzzers exhaustively iterate through a specific target format 
or network protocol. They can be used to stress test a wide range of applications that 
support the target format or protocol. The Modbus/TCP Euzzer (MTE) and scada-tools are 
two custom fuzzers written using Scapy for Modbus and Profinet, respectively [2], [14]. 
Sutton [10] descibes fuzzing frameworks as homogenous development environments that 
enable the use of reusable utilities to maximize extensiblity. Sulley and Peach are examples 
of open-source, generation-based fuzzing frameworks that support some ICS protocols 
[12]. Sulley is a framework consisting of multiple extensible components, including an 
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instrument to monitor the health status of the target and deteet, track, and categorize what 
sequence of test cases triggers faults [10]. Sulley can also fuzz in parallel, increasing 
performance [10]. At DEFCON 15, Devarajan described using the Sulley framework to 
fuzz Modbus, DNP3 and ICCP [15]. Similarly, Peach is designed for flexiblity. It provides 
custom fuzzing strategies and data modifiers, as well as special processes called Agents for 
fault detection [11]. 


Table 3.1. Table of ICS Fuzzers 


Name 

Type 

Protocol 

Availability 

Aegis Fuzzer [16], [17] 

custom 

DNP3, Modbus 

commercially licensed, 
early version open- 

source 

Beyond Security’s beSTORM [18] 

framework 

several, including DNP3 

commercially licensed 

blackPeer [19] 

framework 

several, including Modbus 

NA 

Codenomicon’s Defensics [20] 

framework 

several, including CIP, EtherNet/IP, Modbus, OPC UA 
Server, Profinet, Scada GOOSE 

commercially licensed 

ICCP Fuzzer [21] 

custom 

ICCP 

NA 

LZFuzz [22] 

framework 

several, including SNMP [12] 

NA 

MTF [2] 

custom 

Modbus 

NA 

OPC-MFuzzer [23] 

custom 

OPC, DCOM, RPC [24] 

NA 

OPC Server Fuzzer [25] 

custom 

OPC Server 

NA 

Peach [11] 

framework 

several, including Modbus, BACNet, DNP3, OPC 
[11], [23] 

open-source 

ProFuzz [26] 

custom 

Profinet 

open-source 

scada-tools [14], [27] 

custom 

Profinet 

open-source 

Sulley [28] 

framework 

several, including Modbus, DNP3, TPKT, COPT [15] 

open-source 

Wuldtech’s Achilles [29] 

custom 

several, including EtherNet/IP, Foundation Fieldbus, 
MMS, Modbus, OPC UA, Profinet, DNP3, MMS, 
SES-92 

commercially licensed 
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CHAPTER 4: 
Design 


This research is intended to provide a vulnerability analysis tool for EtherNet/IP. A Scapy- 
based fuzzer for EtherNet/IP was developed to identify anomalies triggered by sending 
malformed input to the system under test (SUT). The fuzzer is general enough to support 
testing all implementations of EtherNet/IP 

4.1 Design Goals 

ENIP Euzz is a custom fuzzer for testing security vulnerabilities in the EtherNet/IP and CIP 
layers of an EtherNet/IP stack implementation. Herein, unless explicitly specified, the term 
EtherNet/IP denotes both layers. This research proposes remote analysis strategies employ¬ 
ing a liveness check, unexpected responses, and performance measurement to monitor the 
remote device during testing. We describe these strategies further in Section 4.2. Next we 
outline each of the components used to support this strategy, and their goals. 

4.1.1 SUT 

ENIP Euzz can be applied to both software and hardware implementations of EtherNet/IP 
(see Section 2.2). While flaw discovery at other implementation of the EtherNet/IP stack of 
the SUT is possible, it is out of scope of our initial study. These out-of-scope flaws include 
those in the SUT when handling malformed packets at layers carrying the EtherNet/IP data, 
such as the TCP, CompoNet, ControlNet and DeviceNet transports. 

4.1.2 Background Traffic 

This study utilizes background traffic to facilitate remote monitoring and fault detection. 
The primary role of the background traffic generators are to produce remote requests to 
the SUT. A client device or client software application may be programmed to generate 
requests to act as background traffic during testing. 
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4.2 Approach 

ENIP Fuzz is developed to fuzz fields within ENIP and CIP request packets. There are three 
ways the fuzzer remotely monitors for faults generated when fuzzing: a liveness check, 
unexpected responses, and performance degradation. 

Many existing fuzzing approaches attach a debugger to the SUT to determine when crashes 
occur. For example, Basnight uses an available Joint Test Action Group (JTAG) interface 
for debugging the Allen Bradley ControlEogix E61 CPU [30]. Debugging with JTAG 
requires special pins called test access ports which may not be available in all devices. 
Other studies have leveraged built-in fault monitoring utilities. Dunlap describes using a 
task monitor utility available in the ControlEogix E61 to access timing data from ladder 
logic execution times for an anomaly based intrusion detection system [31]. Attaching 
a debugger or performance monitor is not an option for our experiments, so we adopt 
alternative, remote-fault monitoring methods. 

Since explicit interaces for fault detection are not always available, people have used remote 
analysis to determine when crashes have occured. Shapiro et al. describe using a liveness 
check to identify when an ICS device revives itself during a fuzzing session [12]. Their 
study suggests that for protocols running over TCP, the occurrence of a TCP RST flag is 
a sufficient metric for indicating that a target device has crashed; however they concede 
that this method may produce false positives. Similarly, Voyiatzis et al. argue that direct 
access to the SUT is not needed, simply a network connection to it [2]. They suggest that 
through network behavior—such as socket timeout, reset, or close; failure in reopening a 
closed socket; and failure in opening a new socket—are useful indications that the SUT has 
crashed. ENIP Fuzz utilizes such indicators to judge if the target has crashed. 

ENIP Fuzz also filters for unexpected responses. Voyiatzis et al. record information during 
fuzzing the Modbus protocol to check if responses were outside of the specification [2]. 
Similarly, ENIP Fuzz inspects response packet data for responses that do not conform to the 
specification. 

For monitoring performance when fuzzing, a baseline of valid traffic for each generator 
is recorded and compared to the traffic captured during fuzzing. These baselines serve 
as a control, modeling how the device should behave under normal operation (e.g., valid 
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EtherNet/IP requests). Records captured during fuzzing are compared to the baseline and 
analyzed for irregularities in response times. Any anomalous behavior is correlated with 
fuzz scenario, using timestamps and packet inspection. 

To our knowledge, no other study has considered performance as a type of fault for detection 
during fuzzing. The NIST Guide to Supervisory Control and Data (SCADA) and Industrial 
Control Systems Security highlights that ICSs are generally time critical, where delay 
of information cannot be tolerated [32]. Thus, malformed packets impacting the timely 
delivery of responses may be considered a type of soft failure, causing the SUT to go 
outside normal behavior. One of the contributions of our study is in exploring three 
potential performance metrics during fuzzing (discussed further in Section 4.3) to ascertain 
their reasonableness as candidates for detecting these types of soft failures. 

4.3 Environment 

Four principal components make up our environment: the SUT, the fuzzer, background 
traffic generators, and the monitor. The test equipment for the experiments consists of an 
Allen Bradley MicroLogix 1100 PLC, a Windows 7 Virtual Machine (VM) with RSLinx, a 
Kali 2.0 VM with the fuzzer, a Kali 2.0 VM with the Ping utility, and a workstation with Mac 
OS X running Wireshark. The equipment are connected via Ethernet to a common hub. The 
SUT employed in this study is the Allen Bradley MicroEogix 1100 PEC, 1763-E16BWA 
Series B, firmware version 14. The MicroEogix 1100 is an EtherNet/IP EO scanner device 
that supports explicit messaging. Experimental traffic sent to the SUT is generated by a 
Kali 2.0 host running ENIP Fuzz. The background traffic generators are two hosts: Kali 
2.0 running Ping and Kali 2.0 running RSEinx. The Ping utility is used to send ICMP 
Echo Requests at one second intervals. RSEinx is software for Allen Bradley devices used 
to browse and configure PEC devices. To generate requests, RSEinx is set to autobrowse 
mode, causing it to send UDP broadcast EtherNet/IP Fist Identity Response requests to 
the SUT (and, in fact all devices connected to the network). The monitor is Mac OS X 
host running Wireshark to collect all traffic for analysis. Figure 4.1 shows these elements, 
connected in the test environment. 
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Figure 4.1. Design of Fuzzer 


This figure illustrates the fuzzing test environment. 


During experimentation, a liveness eheck is performed using the Ping utility to determine 
that the target is still responsive. For performanee degradation, we monitor the lateney 
in responses to both ICMP Eeho Requests and EtherNet/IP requests made by the RSEinx. 
Irregularities in reeorded response times may suggest inereased CPU utilization or memory 
exhaustion related to fuzz testing. The SUT is also monitored for unexpeeted responses, ie, 
responses outside the EtherNet/IP speeifieation or otherwise ineorreet (e.g., responses that 
eontaining data). 
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CHAPTER 5: 

Implementation and Analysis 


This chapter provides details on the implementation of ENIP Fuzz and an analysis of 
the results from experimentation. First we discuss the implementation of an EtherNet/IP 
support library, followed by the implementation of ENIP Fuzz. We then describe the three 
EtherNet/IP service requests that were fuzzed, the results of this experimentation, and a 
denial of service (DoS) fault that was discovered. 

5.1 Implementation of Support Library 

ENIP Fuzz is supported by an EtherNet/IP support library that was built using Scapy, 
a Python module used for packet crafting and manipulaiton [5]. This library was built 
conforming to specification and leveraged Wireshark’s dissector for EtherNet/IP protocol 
parsing [8], [33]. Wireshark versions 1.0.0 to 2.0.4 ships with an EtherNet/IP plugin 
[34]. ENIP Fuzz is not a one-to-one translation of Wireshark’s source code, which is 
written in C. Internally, they are not the same; instead, Wireshark was used for validating 
data field structure rather than reuse of its parsing logic. In fact, we discovered errors 
in Wireshark’s implementation of the CIP Common Services, specifically the Muliple 
Service Packet [8, §A-4.10]. Additionally, Wireshark does not support proprietary vendor 
specific EtherNet/IP implementations, such as Allen Bradley’s Programmable Controller 
Communication Commands (PCCC) protocol [35]. 

ENIP Fuzz is complete in its support of the EtherNet/IP specification [33] and approximately 
one fourth of the CIP specification [8]. To characterize the EtherNet/IP traffic space we 
collected several samples of communication from our ICS lab environment, which included 
the AB/RA MicroEogix 1100 and ControlEogix 5570 devices. From these traffic captures 
we priotized our coverage of the specification and implemented every EtherNet/IP and CIP 
service that was observed. In addition, we added support for Allen Bradley’s proprietary 
implementation of EtherNet/IP, PCCC [35]. 
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5.2 Implementation of Fuzzer 

Based on observed traffic in our lab, three types of EtherNet/IP service requests were chosen 
as test cases to fuzz: EtherNet/IP RegisterSession, CIP NOP, and Execute PCCC Service. 
Eor each of these, fields were selected as primitives to fuzz based on the observed volatility 
in the field’s value. Eields that remained static after having been assigned a constant value, 
like the Session Handle, a field used for a unique identifier, were not fuzzed. Additionally, 
fuzzing was performed only at the layer in which the service request is encapsulated. Each 
EtherNet/IP service request is encapsulated at a different layer, which means that across the 
three tests we were fuzzing fields in each of these three layers: EtherNet/IP (for EtherNet/IP 
Register Session), CIP (for CIP NOP), and PCCC (for Execute PCCC Service). The 
following sections provide more detail on these services and how each were fuzzed. 

5.2.1 EtherNet/IP RegisterSession Request 

The EtherNet/IP RegisterSession Request is used for establishing a TCP encapsulation 
session between an originator and a target. As defined by the specficiation [33, §2-4.4], 
the originator shall open a TCP/IP connection to the target on port 0xAP12; the originator 
shall then send an EtherNet/IP RegisterSession request to the target. Upon receiving a 
valid RegisterSession request, the target shall assign and reply with a unique a session 
identifier called the Session Handle, an unsigned 32-bit integer value [33]. Eigure 5.1 and 
5.2 illustrates the structure of the Register Session request. 
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###[ ENIP TCP I### 

Ccmmand 
Length 
Session 
Status 
Sender Context=ieil 
Options 

###[ Register Session 
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Figure 5.1. An Example EtherNet/IP Register Session Request 

An Example EtherNet/IP Register Session Request as output by our support library, 
highlighting fields encapsulated at the EtherNet/IP layer. 
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Figure 5.2. Packet Structure of an Example EtherNet/IP Register Session 
Request 


This figure illustrates the packet structure of an Example EtherNet/IP Register 
Session Request as output by our support library, highlighting fields encapsulated 
at the EtherNet/IP layer. 


To fuzz the EtherNet/IP Register Session Request, we manipulated the Protoeol Version 
and Options Flags, first in isolation and then simultaneously. Both of these fields take the 
value of an unsigned 16-bit integer value. For eaeh test ease, ENIP Fuzz is programmed to 
fuzz these fields with a random integer from 0 to 65535. Per the speeification [33, §2-4.4] 
and experimentation, with the exeeption of Session Handle, these are the only non-eonstant 
fields. 
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5.2.2 CIP NOP Request 

The CIP NOP (No Operation) Request is a CIP eommon serviee that eauses the reeeiving 
object to generate a No Operation response [8, §A-4.17]. The object receiving the CIP NOP 
request does not execute any other internal action; if the object does not support the CIP 
NOP, a response with a status error is returned [8, §A-4.17]. The CIP NOP Request was 
chosen because of its simplicity. The CIP NOP has no specified data field structure and is 
only embedded in an EtherNet/IP Send RR Data Packet. Figures 5.3 and 5.4 illustrate the 
structure of a valid CIP NOP. 


###[ 


###[ 

###[ 


###[ 


ENIP TCP ]### 

Comniand ■ Send RR Data (0x6F) 

Length = 22 

Session_Handle= 0xf3ec3baf 
Status = Success (0x00000000) 
Sender_Context= 0 
Options = 0 
Send RR Data )### 

Interface_Handle= 0 
Timeout = 0 


ENIP_CommonPacketFormat ]### 

Item_Count= 2 
\Items \ 

!###[ Common Packet Format Item )### 

I Address_Data_Item= Null (0x0000) 

I Address_Length= 0 

!###[ Common Packet Format Item ]### 

I Address_Data_Item= Unconnected Message (0x62) 

I Data_Length= 6 
Common_Industrial_Protocol ]### 

Request_Response= IReguestl 
Common_Service= NOP I(0xl7n 
Request_Path_Size= 2 
\Words \ 

!###( CIP Request Pat h ]#»» 

I Path_Segment_Type= | Logic al Seg ment] 

I Loqical_Seqment_Tvpe=Tciass ID I _ 

I Logical_Segment_Format^8-bit log ical address! 
I Class = Identity Object (0x1) 

!###[ CIP Request Path ]### 


Path_Segment_Type=[Lo gical Segment! 
Logical_Segment_Type= 

LogicaI Segment For maf= 

Eight bit Instance= l0x1 


I nstance ID _ 

8-bit logical addressi 


Figure 5.3. An Example CIP NOP Request 

An Example CIP NOP Request as output by our support library, highlighting fields 
encapsulated at the CIP layer. 
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Figure 5.4. Packet Structure of an Example CIP NOP Request 

This figure illustrates the packet structure of an Example CIP NOP Request as 
output by our support library, highlighting fields encapsulated at the CIP layer. 


As the CIP NOP does not have any assoeiated data field strueture, the Class and Instance 
fields within the Request Path were fuzzed individually and then at the same time. Class and 
Instance are a type of CIP segment used for referencing a specific CIP entity [8]. Segments 
are grouped together in order to define a relationship among different objects. The Request 
Path is a value used to specify such a relationship. 

5.2.3 Execute PCCC Service 

PCCC is a Rockwell Automation vendor-specific application-layer protocol used for com¬ 
munication between certain Allen Bradley processors [35]. Unlike the EtherNet/IP Register 
Session and CIP NOP, the Execute PCCC Service is not a common service. According to 
Allen Bradley, PCCC is used primarily to “ease communication between legacy networks 
and the new CIP networks” [36, p. 7.17]. EtherNet/IP products are able to support PCCC 
through encapsulation within CIP The RSEogix 500 Software, used to program ladder logic 
for Allen Bradley PECs, was observed in our lab to send Execute PCCC Service commands. 
The high regularity with which that software would send the Execute PCCC Service was 
the motivating factor in its selection for fuzzing. The protected typed logical write with 
three address fields was the specific Execute PCCC Service function chosen for fuzzing. 
Eigures 5.5 and 5.6 illustrate a valid command of this type. This function is used to read 
data from a logical address [36, p. 7.17]. To fuzz this function the following fields were 
manipulated in isolation and then in combination: Byte Size, Eile Number, Eile Type, and 
Element Number. 
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###[ ENIP TCP ]### 

Command = Send Unit Data (0x0070) 

Length = 45 

Session_Handle= 0xbf666394 
Status = Success 
Sender_Context= 0 
Options = 0 
###[ Send Unit Data ]### 

Interface_Handle= 0 
Timeout = 20 

###[ ENIP_CommonPacketFormat ]### 

Item_Count= 2 
\Items \ 

!###[ Common Packet Format Item ]### 

I Address_Data_Item= Connection-Based (0X00A1) 

I Address_Length= 4 
I Connection_Identifier= 0x94637520 
!###[ Common Packet Format Item ]### 

I Address_Data_Item= Connected Transport Packet (0x0061) 
I Data_Length= 25 
I Sequence_Number= 0x1 
###[ Common_Industrial_Protocol )### 

Request_Response= Request 
Common_Service= Execute_PCCC_Service 
Request_Path_Size= 2 
\Words \ 

!###[ CIP Request Path ]### 

I Path_Segment_Type= Logical Segment 
I Logical_Segment_Type= Class ID 
I Logical_Segment_Format= 8-bit logical address 
I Class = 0x67 
[###[ CIP Request Path )### 

I Path_Segment_Type= Logical Segment 
I Logical_Segment_Type= Instance ID 
I Logical_Segment_Format= 8-bit logical address 
I Eight_bit_Instance= 0x1 
###[ CIP Execute PCCC Service Request ]### 

Length of Requestor ID=r7l 

CIP_Vendor_ID_of_Requestor= iRockwell Software, In^H 
CIP_Serial_Number= 90180339 
CHD = 0X0F 

Status = 0x0 

T ransaction_Word=[2 


Function = 
Byte Size = 
File No = 
File_Type = 
Element No= 

ProtecTed_Typed_Loqical_Read_Three_Add ress_Fields) 

0X1 


0X0 

0X0 

Sub_Element_ 

No= 

0^ 


Figure 5.5. An Example Execute PCCC Service 

An Example Execute PCCC Service - Protected Typed Logical Write with Three 
Address Fields as output by our support library, highlighting fields encapsulated at 
the PCCC layer. 
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Figure 5.6. Packet Structure of an Example Execute PCCC Service 

This figure illustrates the packet structure of an Example Execute PCCC Service as 
output by our support library, highlighting fields encapsulated at the PCCC layer. 


5.3 Results and Analysis 

As described in Chapter 4, we identified three metrics for analysis: the deltas between 
ICMP Echo requests from Ping, List Identity requests from RSLinx, and the response 
from the service request being fuzzed. The SUT interacts with the traffic generators for 
about 5 minutes during a "warm-up period," after which the fuzzer sends either correctly 
formed packets (during baseline) or malformed packets (during testing) for a period of 
approximately 20 minutes. The Wireshark dump of the fuzzing session is then truncated 
into a 10 minute window, after which each of the metrics are investigated for analysis. Each 
delta is calculated by taking the difference between the timestamp of the response and the 
request. 

We performed three baseline measurements and fourteen trials. Each baseline and trial is 
repeated twice making the total number of tests twenty-eight. Table 5.1 summarizes each 
trial that was performed. 

Our results suggest that using the deltas in response times from ICMP Echo requests and 
List Identity requests may not be meaningful metrics for determining whether fuzzing has 
an observable effect on the performance of the SUT. Using the Tukey’s Honest Significant 
Difference (HSD) test there is no significant difference in response times when fuzzing 
compared to when sending non-malformed traffic. Eigure 5.8 and Eigure 5.9 illustrates 
Tukey HSD graphs for the fuzzing metric with the EtherNet/IP Register Session and CIP 
NOP commands, respectively. In this example, we see that all populations appear to 
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Table 5.1. Table of ICS Fuzzing Trials 


Trial Name 

Layer 

Eield Euzzed 

enip-register-session-baseline 

EtherNet/IP 

NA 

enip-register-session-fuzz-protocol-version 

EtherNet/IP 

Protocol Version 

enip-register-session-fuzz-option-flag 

EtherNet/IP 

Options Elags 

enip-register-session-fuzz-protocol-option 

EtherNet/IP 

Protocol Version, Options Elags 

cip-nop-baseline 

CIP 

NA 

cip-nop-fuzz-class 

CIP 

Class 

cip-nop-fuzz-instance 

CIP 

Instance 

cip-nop-fuzz-class-instance 

CIP 

Class, Instance 

pccc-exec-baseline 

PCCC 

NA 

pccc-exec-fuzz-byte 

PCCC 

Byte Size 

pccc-exec-fuzz-file-no 

PCCC 

Eile Number 

pccc-exec-fuzz-file-type 

PCCC 

Eile Type 

pccc-exec-fuzz-element 

PCCC 

Element Number 

pccc-exec-fuzz-all 

PCCC 

Eile Number, Eile Type, Element Number 


overlap, therefore the null hypothesis (that the samples represent the same distribution, i.e., 
the latencies were unaffected) cannot be rejected. 

On the other hand, with Tukey’s HSD test for the fuzzing metric with the Execute PCCC 
Service command, we observed some sensitivity in the metric. Figure 5.7 is a Tukey 
HSD graph of the fuzzing the metric for tests run on the Execute PCCC Service. The 
graph suggests the performance may be a good metric for analysis, however the results are 
inconsistent. For example, when comparing pccc-exec-fuzz-file-no-1 and pccc-exec-fuzz- 
file-no-2 we expected that the mean latencies would overlap based on tests performed on 
EtherNet/IP Register Session and CIP NOP test cases, but instead we observe a statistical 
difference between these populations. We observe similar anomalous results when com¬ 
paring pccc-exec-fuzz-byte-1 with pccc-exec-fuzz-byte-2. (See Appendix B for a more 
detailed discussion of our analysis using Tukey HSD.) 
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pccc-exec-fuzz-fiie-type-2-fuzzer.pcap 

pccc-exec-fuzz-fi!e-type-l-fuzzer.pcap 

pccc-exec-fuzz-file*no-2-fuzzer.pcap 

pccc-exec-fuzz-file*no-l*fuzzer.pcap 

pccc-exec-fuzz-element-2-fuzzer.pcap 

pccc-exec-fuzz-element-l-fuzzer.pcap 

pccc-exec-fuzz-byte-2-fuzzer.pcap 

pccc-exec-fuzz-byte-l-fuzzer.pcap 

pccc-exec-fuzz-all-2-fuzzer.pcap 

pccc-exec-fuzz-all-l-fuzzer.pcap 

pccc-exec-baseline-2-fuzzer.pcap 

pccc-exec-baseline-l-fuzzer.pcap 


Figure 5.7. Tukey HSD on Fuzz Tests of Execute PCCC Service 

This graph is a Tukey HSD comparison between the fuzz tests on the Execute 
PCCC Service 


Multiple Comparisons Between All Pairs (Tukey) 



cip-nop-fuzz-instance*2-fuzzer.pcap 

dp-nop-fuzz-instance-l-fuzzer.pcap 

cip-nop-fuzz-class-instance-2-fuzzer.pcap 

cip-nop-fuzz-class-instance-l-fuzzer.pcap 

cip-nop-fuzz-class-2-fuzzer.pcap 

cip-nop-fuzz-class-l-fuzzer.pcap 

cip-nop-baseline-2-fuzzer.pcap 

cip-nop-baseline-l-fuzzer.pcap 


Figure 5.8. Tukey HSD of Fuzz Tests on EtherNet/IP Register Session 

This graph is a Tukey HSD comparison between the fuzz tests on the EtherNet/IP 
Register Session. 
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Figure 5.9. Tukey HSD Fuzz Tests on CIP NOP 
This graph is a Tukey HSD comparison between the fuzz tests on the CIP NOP. 
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5.3.1 Denial of Service Fault 

When fuzzing the Execute PCCC Service, a DoS service fault was triggered. This result 
is not represented in the deltas discussed previously; we identified the type of packet that 
caused the fault and bypassed it to produce the the results in Figure 5.7. By sending a 
specially crafted Execute PCCC Service packet to the SUT a Major Error (0x8) is triggered 
and the device becomes unresponsive. To clear the fault the device to continue operations, 
the device must be power-cycled and re-set using the RSEogix Clear Major Fault utility. 
Figure 5.10 is the hex output of the Status File during the Faulted state. A report on the 
DoS fault is available in Appendix A. 
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Figure 5.10. MicroLogix 1100 Status File 

This figure is the hex output of the MicroLogix 1100 Status File during the Faulted 
state. 


It appears that this is a previously unreported DoS vulnerability caused by accessing certain 
Data Files with an invalid File Type. According to the MicroLogix 1100 reference manual, 
data files store status and data information associated with instructions used in ladder 
subroutines [37, p. 40-41]. CVE-2012-4690 describes of a DoS fault caused when a 
malformed CIP packet is written to the Status file [38]. It is not clear if these two faults are 
related as our fault does not involve any write requests. Allen Bradley has issued firmware 
releases for the MicroLogix 1100 to mitigate this vulnerability. We currently use Firmware 
Revision Number (FRN) 14 and, according to the release notes for this version, the anomaly 
identified in CVE-2012-4690 was corrected in ERN 13: “Status file bits [...] were write 
able through communication messages which allowed the possibility to force the controller 
to go into fault. The solution included in this firmware revision allows users to CEEAR 
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these bits [...] but does NOT allow them to SET using Communieation Messages” [39, p. 
5]. Moreover, the observed fault is generated by a read request. 
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CHAPTER 6: 
Conclusion 


The diversity and complexity of embedded control systems on Navy afloat and ashore 
platforms make it difficult to protect them. The use of industrial components that implement 
proprietary protocols further exacerbates the problem. This chapter presents a summary of 
the results and findings of our attempt to address this impediment, and provides suggestions 
for follow-on work. 


6.1 Summary 

Prior to development, we investigated the strengths and weaknesses of two known fuzzing 
approaches: mutation-based and generation-based. We found that mutation-based fuzzing 
requires less up-front research to understand the specifications of the SUT and more test¬ 
ing effort to obtain sufficient code coverage. Generation-based testing, on the other hand, 
requires detailed understanding of the SUT to construct grammar-based test specifications. 
Furthermore, we surveyed existing fuzzing frameworks and fuzzers to determine the avail¬ 
ability of EtherNet/IP fuzzers. We found two custom Scapy-based fuzzers for other common 
industrial protocols, i.e., Modbus and Profinet, but to the best of our understanding, there 
is no open-source fuzzer supporting EtherNet/IP or CIP. 

We developed a Scapy-based fuzzer and a packet dissector library that could handle Eth¬ 
erNet/IP packets with encapsulated CIP and PCCC messages. We validated our dissector 
with a packet capture corpus that included EtherNet/IP traffic generated by two different 
AB/RA platforms, i.e., MicroEogix 1100 and ControlEogix 5570. We used a MicroEogix 
1100 as the SUT for our fuzzer. 

While stress testing the MicroEogix llOO’s handling of PCCC messages, we discovered a 
potential flaw in its implementation of the Execute PCCC Service request. We searched the 
ICS-CERT vulnerability database and did not find any vulnerability report describing the 
observed deficiency. Proper input validation should resolve this vulnerability. Our ability 
to cause a DoS fault by sending a single, specially-crafted PCCC Execute Service packet 
suggests that there could be other exploitable vulnerabilities in the MicroEogix’s EtherNet/ 
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IP software. 


Another eontribution is the use of network response times as a metrie for fault deteetion. 
Tukey HSD tests performed suggests there is no signifieant differenee between the response 
times eaptured during normal aetivity and the response times eaptured during fuzz testing. 

6.2 Future Work 

As an extension to this work, the EtherNet/IP support library ean be expanded so that it 
is fully eompliant with the speeifieation [33] [8]. Better handling of propiertary protoeols 
sueh as PCCC should also be added [36]- eurrently, these protoeols are not supported 
by Wireshark’s disseetors, and thus must be validated through alternative means, sueh as 
manual inspeetion of traffie. 

A eustom utility that ean ealculate lateney deltas in request and response in finer granularity 
may help improve the remote performanee monitoring eapability. Presently, deltas in request 
and response are ealeulated using timestamps observed in Wireshark dumps. For better 
preeision, we may eonsider building our own utilities to ealeulate latencies in response. 

We intend to use ENIP Fuzz to test other EtherNet/IP devices. It is possible that other 
PCCC implementations are vulnerable to the same Execute Service fault we discovered. 
Additionally, investigating the TCP and IP layers of the network stack may also expose 
vulnerabilities relating to the assumptions made by the EtherNet/IP implementations about 
the underlying TCP/IP mechanisms. 
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APPENDIX A: 

AB/RA MicroLogix 1100 DoS Vulnerability 


We are reporting an exploitable read operation vulnerability for the Allen Bradley Rockwell 
Automation MicroLogix Programmable Logic Controller (PLC) implementation of the 
Execute PCCC service request. By sending a single, specially-crafted PCCC Execute 
Service packet an attacker will cause the device to fault. We tested this on the Allen Bradley 
MicroEogix 1100 Programmable Eogic Controller, 1763-E16BWA Series B, ERN 14. 

A.l Exploit Proof-of-Concept 

To exploit the vulnerability, the attacker sends a single Execute PCCC Service - Protected 
Typed Eogical Read with Three Address Eields packet with a Pile Number of 0x2 to 0x8 and 
Pile Type 0x48 or 0x47. Any combination of Pile Number 0x2 to 0x8 and Pile Type 0x48 
or 0x47 will trigger a Major Error (0x8). Pigures A.l and A.2 illustrate example packets 
that will cause the fault. 
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###( ENIP TCP 1### 

Command = Send Unit Data (0x0070) 

Length = 45 

Session_Handle= 0x6077596d 
Status = Success 
Sender_Context= 0 
Options = 0 
###[ Send Unit Data ]### 

Interface_Handle= 0 
Timeout = 20 

###[ ENIP_CommonPacketFormat ]### 

Item_Count= 2 
\Items \ 

!###[ Common Packet Format Item )### 

Address_Data_Item= Connection-Based (0X00A1) 
Address_Length= 4 
Connection_Identifier= 0xedS96902 
!###[ Common Packet Format Item ]### 

Address_Data_Item= Connected Transport Packet (0X00B1) 
Data_Length= 25 
Sequence_Number= 0x1 
###[ Common_Industrial_Protocol ]### 

Request_Response= Request 
Common_Service= Execute_PCCC_Service 
Request_Path_Si 2 e= 2 
\Words \ 

!###[ CIP Request Path ]### 

Path_Segraent_Type= Logical Segment 
Logical_Segment_Type= Class ID 
Logical_Segment_Format= 8-bit logical address 
Class = 0x67 
!###[ CIP Request Path ]### 

Path_Segment_Type= Logical Segment 
Logical_Segment_Type= Instance ID 
Logical_Segment_Format= 8-bit logical address 
Eight_bit_Instance= 0x1 
###[ CIP Execute PCCC Service Request ]### 

Length_of_Requestor_ID= 171 

CIP_Vendor_ID_of_Requestor= IRockwell Software. IncTI 
CIP_Serial_Number= 90180339 
CHD = (0x07] 

Status = 0x0 

Transaction Word= fTI 



Function = 
Byte_Si 2 e = 
File_No 
File_Type = 
Element No= 


Protected Typed Logical Read Three Address Fields! 


Figure A.l. An Example DoS Packet 
An Example DoS Packet, highlighting fields encapsulated at the PCCC layer. 
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Figure 

A.2. 

Packet Structure 

of an Example DoS Packet 




This figure illustrates the packet structure of an Example DoS Packet, highlighting 
fields encapsulated at the PCCC layer. 


In addition, to reproduce the fault, it appears that the attacker must establish a session 
with the target with an EtherNet/IP Register Session Request and then create a connection 
instance with a Connection Manager Forward Open Request. Figure A.3 is a screenshot 
of a Wireshark capture detailing the order that packets are sent. Figure A.4 demonstrates 
that the DoS packet does not have to immediately follow the Connection Manager Forward 
Open Request to cause the fault. 


No. I Time | Source | Destination | Protocol | Length | Response time |lnfo 

19 1<169691262.67«I81 192.16B.0.62 192.168.0.S9 Et4IP 82 Flegister Session (Req), Session: OxOOOOOOOO 

20 1469691262.678661 192.168.0.S9 192.168.0.62 ENIP 82 Register Session (Rsp), Session: 0i<6077S96D 

22 1469691262.874917 192.168.0.62 192.168.0.59 QP 01 140 Fon«nl Open 

23 1469691262.888068 192.168.0.59 192.168.0.62 QP CM 124 Success 



[TCP Retiananission] | JnknCMn Ser\iic.r ' 

(TCP Fletnnsussion] | Unkncwn Servioe iCi' i: 
[TCP Retransussion] | UiAnoian Service (0«4b' 
[TCP Retransoission] j Unknown Service (0«4b' 
[TCP Retransussion] j Unknown Service (0t4b' 


- - ■ . 

^ Fiaiie 25: 123 bytes on wire (984 bits), 123 bytes captured (9B4 hits) 

> Etherret II, Srt: CadmusCo.ec:ll:8c (0e:00:27:ec:ll:ec), Ost: RockMell.al:28:4c (00:ld:9c:al:28:4c) 

> Internet Protocol Version 4, Src: 192.168.0.62 (192.168.0.62), Ost; 192.168.0.59 (192.168.0.59) 

> Transnission Control Protocol. Src Port: 47964 (47964), Ost Port: 44818 (44818), Seq: 1611555071, Ack: 129 7288568, Len: 69 

> EtherMet/IP (Industrisl Protocol), Session: 0ii60775960, Send Unit Data 
^ Ccrmon Irdustrul Protocol 

> aP Class Generic 


0000 
0010 

0030 
0040 
0050 
0060 
0070 

Figure A.3. Wireshark Capture of the Packet Flow of the DoS Fault 

A screenshot of a Wireshark capture of an example packet flow that will cause the 
DoS Fault. 


00 Id 9c al 28 4c 08 00 27 ec 11 Be 00 00 45 00 ....(L.. ' E 

00 6d dc c9 40 00 40 06 db f7 cO a8 00 3e cO aO .>..^.0.>. 

00 3b bb Sc af 12 60 Oe 60 ff 4d 53 Od 70 50 10 .;.\.. . .MS.xP 

72 10 e3 Of 00 00 70 00 2d 00 Sd 59 77 60 00 00 r.p. -.rriYw'. 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . 

00 00 14 00 02 00 al 00 0 4 00 0 2 69 59 6d bl 00 .iYm. 

19 00 01 00 4b 02 a 6 7 24 0 1 0 7 4d 00 f3 Oa 60 ... .K. g }. .H... 

05 Of 00 02 00 a2 00 05 47 00 00 . G.. 
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No. 


I Time | 

22 14696682511.900616 

23 1469668254.910437 

25 1469668251.977364 

26 1469688251.990200 

28 14696BB25S.031485 

29 1469668255.040625 

31 1469668255.054236 

32 1469666255.060214 


I Source 

192.168.0.62 

192.168.0.59 

192.168.6.62 

192.168.0.59 

192.168.0.62 

192.168.0.59 

192.168.0.62 

192.168.0.59 


I Destination | Protocol 

192.166.0.59 ENIP 

192.168.0.62 ENIP 

192.166.6.59 aP 01 

192.168.0.62 QP 01 

192.168.0.59 aP 

192.168.0.62 QP 

192.166.0.59 QP 

192.166.0.62 aP 


Length | Response time 
62 
82 
140 
124 
123 
115 
123 
115 


I Info _ 

Flegister Session (Req), Session: 0x00000000 
Register Session (Rsp), Session: 0xSSSF0F4C 
ForvartJ Open 

Unknown Service (0x4b) 

Unknown Service (0x4b) 



- - - - • - =» 

> Frame 33: 123 bytes on wire (984 bits). 123 bytes captured (984 bits) 

> Ethernet II, Sre: CadiMisCo.ec:ll:6c <06:00:27:ec:Il:8c). Dst: RsckNeU.al:28:4c (00:ld:9c:al:28:4c) 

> Internet Protocol Version 4. Src: 192.168.0.62 (192.168.0.62), Dst: 192.166.0.59 (192.168.0.59) 

> Trananission Control Protocol, Src Port: 47949 (47949), Dst Port: 44616 (44816). Seq: 1053019635. Ack: 1297286690. len: 69 
^ EtherNet/IP (Industrial Protocol). Session: 0 k 5SSF0F4C. Serd Unit Data 

^ Cannon Industrial Protocol 
^ QP Class Generic 


OOOO 00 Id 9c al 28 4c 06 00 
0010 00 6d 8e 34 40 00 40 06 
0020 00 3b bb 4d af 12 3e c3 
0030 72 18 d6 7c 00 00 70 00 
0040 00 00 00 00 00 00 00 00 
0050 00 00 14 00 02 00 al 00 
0060 19 00 03 00 4b 02 20 67 
0070 05 Of 00 04 00 a2 00 02 


27 ec 11 8c 08 00 45 00 
^ 8d d) b 8 00 3e cO aS 
cd f3 4d S3 Od f2 50 18 
2d 00 dc Of Sf 55 00 00 
00 00 00 00 00 00 00 00 
04 00 44 5f Of 4c bl 00 
24 01 07 4d 00 f3 Oa 60 
47 00 00 


Figure A.4. 
DoS Fault 


Wireshark Capture of a Second Example Packet Flow of the 


A screenshot of a Wireshark capture demonstrating a second example packet flow 
that will cause the DoS Fault. 
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APPENDIX B: 
Tukey’s HSD Test Data 


In Section 5.3 we discuss using Tukey’s Honest Significant Difference test to perform 
simultaneous comparison tests on three metrics: the deltas between ICMP Echo requests 
from Ping, List Identity requests from RSLinx, and the response from the service request 
being fuzzed. Our results from those tests suggests there is no significant difference 
response time when fuzzing compared to when sending non-malformed traffic. However 
we did observe some sensitivity with Tukey’s HSD test for the fuzzing metric with the 
Execute PCCC Service. The following sections will go into more detail on our use of 
Tukey’s HSD. 

B.l Tukey’s HSD Means Comparison 

Tukey’s HSD performs simultaneous comparison of independent means. Eigures B.l and 
B .2 are charts comparing all pairs of tests for the fuzzing metric with the EtherNet/IP Register 
Session and CIP NOP, respectively. In this example, we see that, with the exception of the 
three tests, the null hypothesis (that the samples represent the same distribution, i.e., the 
latencies were unaffected) for the fuzzing metric with the EtherNet/IP Register Session and 
CIP NOP cannot be rejected. 
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Multiple Comparison of Means - Tukey H5D,FWER=0.05 


groupl 


3roup2 


meandiff lower upper reject 


enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-l-fuzzer.pcap 
enip-register-session-baseline-2-fuzzer.pcap 
enip-register-ses$ion-baseline-2-fu22er.pcap 
enip-register-session-baseline-2-fuzzer.pcap 
enip-register-session-baseline-2-fu22er.pcap 
enip-regi5ter-ses5ion-baseline-2-fuzzer.pcap 
enip-register-session-baseline-2-fu22er.pcap 
enip-register-session-fuzz-option-flag-l-fuzzer.pcap 
enip-register-session-fu22-option-flag-1-tuzzer.pcap 
enip-register-session-fuzz-option-flag-l-fuzzer.pcap 
enip-register-session-fu22-option-flag-l-fuzzer.pcap 
enip-regi$ter-session-fuz2-optien-flag-l-fuz2er.pcap 
enip-register-session-fuzz-option-flag-2-fuzzer.pcap 
enip-register-session-fu22-option-flag-2-tuzzer.pcap 
enip-register-session-fuzz-option-flag-2-tuzzer.pcap 
enip-register-session-fu22-option-flag-2-fuz2er.pcap 
enip-register-session-fuzz-protocol-option-l-fuzzer.pcap 
enip-register-session-fu22-protocol-option-1-tuzzer.pcap 
enip-register-session-fuzz-protocol-option-l-fuzzer.pcap 
enip-register-session-tuzz-protocol-option-2-tuzzer.pcap 
enip-register-session-fuz2-protocol-option-2-fuz2er.pcap 
enip-register-session-tuzz-protocol-version-1-tuzzer.pcap 


enip-register-session-baseline-2-tuzzer. pcap 
enip-register-session-tuz2-option-tlag-l-fU22er. pcap 
enip-re9i5ter-session-tuzz-option-tlag-2-tuzzer. pcap 
enip-register-session-tuz2-protoco1-option-l-tuzzer. pcap 
enip-register-session-tuzz-protocol-option-2-tuzzer.pcap 
enip-register-session-tuzz-protocol-version-l-tuzzer.pcap 
enip-register-5ession-tuzz-protocol-wersion-2-tuzzer.pcap 
enip-register-session-tuzz-option-tlag-l-tuzzer.pcap 
enip-re9ister-session-tuzz-option-tla9-2-tu22er.pcap 
enip-register-session-tuzz-protocol-option-l-tuzzer.pcap 
enip-register-session-tuzz-protocol-option-2-tu2zer.pcap 
enip-register-session-tuzz-protocol-version-l-tuzzer.pcap 
enip-re9ister-session-tu22-protocol-wersion-2-fu22er.pcap 
enip-register-session-tuzz-option-tla9-2-fuzzer.pcap 
enip-register-session-tuz2-protoco1-option-l-tuzzer. pcap 
enip-register-session-tuzz-protocol-option-2-tuzzer.pcap 
enip-register-session-tuzz-protocol-wersion-l-fuzzer.pcap 
enip-re9ister-session-fuzz-protocol-version-2-fuzzer.pcap 
enip-register-session-tuzz-protocol-option-l-tuzzer.pcap 
enip-re9ister-session-tuz2-protocol-option-2-tu22er.pcap 
enip-register-session-tuzz-protocol-wersion-l-tuzzer,pcap 
enip-re9ister-session-tu22-protocol-version-2-fu22er.pcap 
enip-re9ister-session-tuzz-protocol-option-2-tu2zer.pcap 
enip-register-session-tuzz-protocol-version-l-tuzzer.pcap 
enip-register-session-tuzz-protocol-wer5ion-2-tuzzer.pcap 
enip-register-session-tuzz-protocol-wersion-l-fuzzer. pcap 
enip-re9ister-session-fuzz-protocol-version-2-fuzzer. pcap 
enip-re9ister-session-tu2z-protocol-wersion-2-tuzzer.pcap 



- 0.0 


- 0.0001 



-0.0 0.0004 False 

0.0001 0.0005 True 
0.0 0.0004 True 

-0.0 0.0004 False 

0.0 0.0004 True 

-0.0001 0.0003 False 
-0.0 0.0004 False 

-0.0001 0.0003 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0003 0.0001 False 
-0.0002 0.0001 False 
-0.0003 0.0001 False 
-0.0003 0.0001 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0003 0.0001 False 
-0.0003 0.0001 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0002 0.0002 False 
-0.0003 0.0001 False 
-0.0003 0.0001 False 
-0.0002 0.0002 False 


Figure B.l. Tukey’s HSD Multiple Comparison of Means for EtherNet/IP 
Register Session 

This chart compares latency means for the fuzzing metric with the EtherNet/IP 
Register Session. 


Multiple Comparison of Means - Tukey HSD,FWER=0.05 


groupl 


group2 


cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-l-fuzzer.pcap 
cip-nop-baseline-2-fuzzer.pcap 
cip-nop-baseline-2-fuzzer.pcap 
cip-nop-baseline-2-fuzzer.pcap 
cip-nop-baseline-2-fuzzer.pcap 
cip-nop-baseline-2-fuzzer.pcap 
cip-nop-baseline-2-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 


cip-nop-baseline-2-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
cip-nop-fuzz-class-l-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
cip-nop-fuzz-class-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-l-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
cip-nop-fuzz-class-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-l-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
cip-nop-fuzz-instance-2-fuzzer.pcap 
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Figure B.2. Tukey’s HSD Multiple Comparison of Means for CIP NOP 
This chart compares latency means for the fuzzing metric with the CIP NOP. 


On the other hand, Figure B.3 illustrates the sensitivity in the fuzzing metrie for tests run 
on the Exeeute PCCC Serviee. Based on the ineonsisteney in whieh we rejeet the null 
hypothesis, this ehart suggests that there is a statistical difference when comparing sample 
populations. 
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Multiple Comparison of Means - Tukey HSD,FWER=0.05 


groupl 


group2 


pccc-exec-baseline-l-fuzzer.pcap 
pccc-exec-baseline-l-fuzzer.pcap 
pccc-exec-baseline-l-fuzzer.pcap 
pccc-exec-baseline-l-fuzzer.pcap 
pccc-exec-baseline-l-fuzzer.pcap 
pccc-exec-baseline-l-fuzzer.pcap 
pccc-exec-baseline-l-fuzzer.pcap 
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Figure B.3. Tukey’s HSD Multiple Comparison of Means for Execute PCCC 
Service 

This chart compares latency means for the fuzzing metric with the Execute PCCC 
Service. 
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